1. Field of the Invention
The present invention relates generally to data networks, and more particularly to a technique for implementing redundancy of network address translation (NAT) information distributed over a data network.
2. Background
Private networks are commonly connected to the Internet through one or more routers so that hosts (PCs or other arbitrary network entities) on the private network can communicate with nodes on the Internet. Typically, the host will send packets to locations both within its private network and on the Internet. To receive packets from the Internet, a private network or a host on that network must have a globally unique 32-bit IP address. Each such IP address has a four octet format. Typically, humans communicate IP addresses in a dotted decimal format, with each octet written as a decimal integer separated from other octets by decimal points.
Global IP addresses are issued to enterprises by a central authority known as the Internet Assigned Number Authority (“IANA”). The IANA issues such addresses in one of three commonly used classes. Class A IP addresses employ their first octet as a “netid” and their remaining three octets as a “hostid.” The netid identifies the enterprise network and the hostid identifies a particular host on that network. As three octets are available for specifying a host, an enterprise having class A addresses has 224 (nearly 17 million) addresses at its disposal for use with possible hosts. Thus, even the largest companies vastly underuse available class A addresses. Not surprisingly, Class A addresses are issued to only very large entities such as IBM and ATT. Class B addresses employ their first two octets to identify a network (netid) and their second two octets to identify a host (hostid). Thus, an enterprise having class B addresses can use those addresses on approximately 64,000 hosts. Finally, class C addresses employ their first three octets as a netid and their last octet as a hostid. Only 254 host addresses are available to enterprises having a single class C netid.
Unfortunately, there has been such a proliferation of hosts on the Internet, coupled with so many class A and B licenses issued to large entities (who have locked up much address space), that it is now nearly impossible to obtain a class B address. Many organizations now requiring Internet access have far more than 254 hosts—for which unique IP addresses are available with a single class C network address. It is more common for a mid to large size enterprise to have 1000 to 10,000 hosts. Such companies simply can not obtain enough IP addresses for each of their hosts.
To address this problem, a Network Address Translation (“NAT”) protocol has been proposed. See K. Egevang and P. Francis, “The IP Network Address Translator (NAT),” RFC 1631, Cray Communications, NTT, May 1994 which is incorporated herein by reference for all purposes. NAT is based on the concept of address reuse by private networks, and operates by mapping the reusable IP addresses of the leaf domain to the globally unique ones required for communication with hosts on the Internet. Further, to implement NAT, a translation system must be provided between the enterprise private network and the Internet. In implementation, a local host wishing to access the Internet receives a temporary IP address from a pool of such addresses available to the enterprise (e.g., class C 254 addresses). While the host is sending and receiving packets on the Internet, it has a global IP address which is unavailable to any other host. After the host disconnects from the Internet, the enterprise takes back its global IP address and makes it available to other hosts wishing to access outside networks.
FIG. 1 shows a schematic block diagram of a conventional local area network 110 which utilizes a network address translation protocol for communicating with the Internet 120. In the example of FIG. 1, each network device which forms part of the LAN 110 is assigned a unique local IP address using a private addressing scheme specific to that LAN. Additionally, as shown in FIG. 1, the LAN 110 may include at least one network address translation (NAT) gateway device (e.g. routers 102 and 104) for allowing the LAN devices to communicate with external network devices. Conventionally, the function of NAT devices 102 and 104 is to translate local IP addresses to global IP addresses and vice-versa.
Thus, for example, if node 112 desires to transmit a message (e.g. packet) to an external network node (e.g., node 124) via Internet 120, the device 112 may transmit a packet to gateway router 102, which then dynamically assigns a global IP address to be associated with device 112, inserts the assigned global IP address into the header of the packet, and forwards the modified packet onto its destination via Internet 120. When the NAT device 102 receives an external packet whose destination corresponds to the globally unique IP address assigned to node 112, the NAT device 102 modifies the header of the external packet by inserting the locally assigned IP address of node 112, and then forwards the packet to node 112 via LAN 110.
Initially NAT was meant to be deployed in stub domains which typically had only one entry/exit path to the Internet. Currently, however, a LAN may include a plurality of NAT routers, wherein each NAT router may serve as a different entry/exit point. As explained in greater detail below, this has created many significant problems, particularly with respect to network reliability and service disruptions.
Generally, conventional NAT routers manage and translate address/port information as packets travel from one realm to another. For continuous flows, this translation information is stored in a repository until that flow expires. As applications become more complex, the flow attachment records include additional context sensitive information that may be necessary while the flow is unexpired. Typically, NAT routers record all such information. However, if, for any reason, a NAT router fails or has to be restarted, the translation repository and context information on that router will be lost, thereby isolating the end points and making the flow unrecoverable due to loss of NAT Table information for these flows. As a result, LAN clients which had been using the failed NAT router will have to restart their applications in order to re-establish connectivity to the Internet using an alternate NAT router.
Moreover, in most conventional NAT systems, the translation repository or address translation table needs to be continually updated on a per-packet basis. This typically results in thousands of translation updates per second, which makes off-box NAT redundancy updates impractical.
In light of the above, it will be appreciated that there is a continuing need to improve upon network address translation techniques in order to provide improved network performance and failover capability.